This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
With 3GPP Rel'8 there is now the inclusion of SIP-I on the Nc interface, where BICC protocol would be replaced as the call control protocol within PLMN, further reference hereto may be found in 3GPP TS 23.231 and TR 29.802 and ITU Q.1902.4, incorporated by reference herein. Such a system is displayed exemplary in FIG. 1 showing the functional split into a user plane comprising the UTRAN and GERAN with respect to their Interface (A-Interface) towards the MediaGateway (MGW) and among MediaGateways (Nb-Interface) and a signaling plane comprising the UTRAN and GERAN with respect to their Interface (Iu-Interface) towards the Mobile Switching Center Server (MSC-S) and among MSC-Server (MSC-Server, Gateway MSC) with the Nc Interface. As shown, the signaling plane is indicated by a dashed line, whereas the User Plane is indicated by a solid line.
Currently, within a BICC based Public Land Mobile Network (PLMN) as an example of a mobile communications network the media gateway selection procedures enable a node to select a media gateway (MGW) which is most suitable for a given traffic case, thereby offering the operator the ability to optimize user plane resources and also enabling flexible routing of the actual payload.
Although in the following, the problems are explained with respect to a mobile communication network, the same problems may arise in a fixed mobile network.
However, the above networks suffer certain problems which will be explained in the following.
In order to have almost the same level of functionality as currently applied to 3GPP BICC layered architecture, in this case optimized MGW selection, SIP-I needs to offer some means of signaling the identity of MGW(s). The MGW could be identified by using either the sent or received user plane connection's Internet Protocol (IP) address. But this assumes all (G)MSC servers know all IP addresses of every MGW and can thus map this to an actual MGW. This is inefficient and unnecessarily complicates the network configuration. This is somewhat analogous to the handling of the Bearer Control Unit Identifier (BCU-Id) in BICC. When BICC is run over IP, it is the BCU-Id that is used for MGW selection, not the connection IP addresses which are swapped via the IP Bearer Control Protocol (IPBCP).
Currently, the concept of MGW identity (or BCU-Id) is not specified in SIP-I; thereby MGW selection optimization is not possible. Without such indication, each (G)MSC server would need to select and use locally configured MGW(s), without utilizing any network knowledge. Further, from a 3GPP perspective, external networks shall always select their own MGW. Thus the GMSC and interworking MSC servers shall also seize a MGW at the network border. In order to offer MGW at the Edge, call establishment procedures need to allow deferred (for mobile originating) or optimized (for mobile terminating) MGW selection.
Deferred MGW Selection
FIG. 2 explains an example of deferred MGW selection that could be applied to SIP-I. In this case, a Session Description Protocol (SDP) offerer is an originating MSC Server which does not signal any MGW identity.
The SDP answerer is an interworking MSC Server which seizes the MGW at its network border and returns its MGW identity to the originating MSC Server. The originating MSC Server now has the ability to select the same MGW. It seizes a bearer termination, indicating in a new second SDP offer to the interworking MSC Server a user plane connection address without any MGW identity.
Optimised MGW Selection
In FIG. 3 is explained an example of optimized MGW selection that could be applied to SIP-I. In this case, the SDP offerer is a GMSC Server which has seized a MGW at the network border. The initial SDP offer indicates that a MGW is connected by including a MGW identity. The SDP answerer is a terminating MSC Server which is able to connect to the same MGW. It seizes a bearer termination in this MGW and returns in the SDP answer both a user plane connection address and used MGW identity.
MGW Negotiation
Not all MGWs may be controlled by all MSC Servers; if this were the case there would be a heavy burden on the operator to configure the network and there would also be the need for a fully meshed transport and GCP signaling network which might not be the case in a network with large geographical coverage and varying traffic densities across the network. Further, not all MGWs, even if they are controlled by all MSC Servers, may support all the same features; pooling of resources may occur in certain MGWs.
It is therefore desired to be able to signal a recommended set of MGWs that would be suitable for a given call and allow the succeeding node or terminating node to select the most suitable MGW that fulfills the requirements of the given call.